Publish and subscribe (pub/sub) messaging uses a message broker to facilitate communications between publishers and subscribers. For example, multiple entities (e.g., users, applications, or the like) can subscribe to an event via the message broker. Subsequently, when the event occurs (e.g., the message broker receives a new message from a publisher), the message broker provides data on the event to the various subscribers.
One of the benefits of a pub/sub messaging system is the decoupling of publishers and subscribers. In particular, the message broker maintains a record of all subscriber endpoints and makes decisions about which subscribers should receive any specific publication, thereby relieving the publisher of these two responsibilities. To this extent, publishers are not required to have any knowledge of the number or detail of subscribers. However, in some situations it is desirable or necessary for a publisher to know the number/details of subscribers to which a publication has been sent.
One approach for providing the publisher with information on the subscribers requires the publisher to query the message broker for details of the subscribers to a relevant topic. The publisher can perform the query either before or after publishing a message to the topic. However, since changes to the subscribers can be made at any time, the details may not accurately reflect the details at the time of the publication. In another approach, the message broker can maintain one or more suitable logs detailing the subscribers to which each publication was forwarded, and make the logs accessible to the corresponding publisher of each publication. However, the data may not be required very often by the publisher, and the publisher must separately query the message broker following each publication for which the data is required.